\chapter{Introduction}
\label{cha:intro}

\section{Motivation}

In certain automated applications it is necessary that several independent systems or agents 
must work together so that a given problem is solved and in such systems redundancy is a very important factor. 
Environments where those agents work in, are these days very dynamic in the sense that things can go wrong or get out of balance. 
In the world were these agents are represented by computers or robots,
everything works on the level of code that must be executed.

In some ways redundancy is already solved by decentralized agent solutions. 
Every task that must be executed in an order such that the whole problem 
is solved is quite straightforward when all independent systems are similar 
and all the tasks are from the same kind. Also when some agent breaks down, 
tasks can be easily integrated into other agents. 

In other applications the independent systems have to handle different types 
of tasks and every agent is different than the other. Thus on the level of
actions or executable code, every task needs different actions and every
agent is not capable of doing some of the actions, does not know if it is
capable to do a certain action or that it just lacks an interface to execute an
action. The reason that every agent cannot handle all the different tasks or
code, could be that the hardware is not supported or other software layers are needed. 
Some other agents may be capable to run that executable code but they are not in
the possession of that code to execute other tasks. So it could be interesting 
that the code is exchangeable between the different systems. 

Another problem arises when some tasks must fit in a schedule. 
If a schedule is not necessary just exchanging the a task with the executable
code is enough. When some tasks need to be finished in time, or that some tasks
depend on each other the problem can get more complex. The techniques used for
just exchanging code must then be extended with some task scheduling.

For example, we have a logistics environment where autonomous trucks must bring
packages from a pickup location to a depot and other trucks must bring the
packages from the depot to the delivery location. These are two types of tasks
that needed to be executed to be done to solve the problem. To execute these tasks
the code of the two types are very different. The trucks drive automatically and
are the independent systems or the agents. Due to physical limitations the
truck that brings packages to the depot can only do those tasks. The other
agents can do both tasks but only are in the possession of the 'delivering'
code. When a truck breaks down and is not able to finish his tasks, those tasks
must be done by collaborating agents. Let us assume that the amount of the
'pickup' agents is very limited, the other pickup agents have very busy
schedules and the delivering agents have calm schedules. So it could be
interesting that the delivering agents could also do some pickup-tasks.
Therefore the code to handle pickup tasks must be made available to the other
agents and must be executable for those agents. This is a problem where the
issue is that some agents can break down.

Another example is when a lot of pickup tasks must be done and some of the
delivering agents have not much work to do. Then a delivery agent can help to 
commit to those tasks and can get and use the executable code to pickup
packages. This example does not tackle a breakdown problem but actually a load
balancing problem.

A final example is where different robots work together in an environment. All
the robots have computational modules, robotic arms, movements modules\ldots . When
an agent is not able to move anymore because of motor problems it will be able
to do heavy computational tasks. the original role of the was just exploring the
environment while another agent did computational tasks. After the breakdown it
benefits if those two agents just exchange their roles and objectives still can
be met.

From the examples we can say that exchanging executable code can be very
interesting for highly dynamic environments. If agents are capable of doing
other tasks than they are supposed to, they just need access to the code for
executing other tasks. Traditional designs in MAS consist of agents with fixed
behaviours. Thus dynamics like described in above examples cannot be handled. For creating such
dynamic agents there is still a great demand for proper agent architectures.

Also in many of those dynamic systems new functionalities can be added to the
agents. The downside is that many systems must be brought down for
updates and that the updating is more of a manual task. The term downtime can be
used here and in modern systems downtime is something that must be minimized.

From the above problems we can formulate a more general problem description :

\begin{itemize}
  \item Current agent architectures are to static and cannot handle very dynamic
  environments.
  \item There is still a great demand and research is still on for developing
  MAS architectures that offers a dynamic role management based on code
 migration.
\end{itemize}


\section{Related Work}

In the a paper \cite{CodeMobility} about code mobility many different
technologies and design paradigms are discussed. This gives first a nice
overview about previous technologies that could be used for exchanging
executable code between agents. Other aspect of this paper handle about design
paradigms in a sense that code mobility can have different meanings.

They explain in the paper some design paradigms and none of those paradigms talk
about exchanging resources with the service that must be executed. That is off
course only applicable when those extra resources are software-based. In out
case some software resources must be exchanged together with the service. and
needs extra investigation.

Since this paper is older than the introduction of the OSGi specifications,
that paper could not have added OSGi as one of the interesting technologies for
code migration. So it could be interesting to investigate if OSGi could have
been a part of that list.

A more recent work \cite{ThesisOSGi} includes the OSGi framework in a
supporting context for our project. That work used OSGi to
build up a network where executable code can be exchanged. OSGi is a framework where dynamically
executable code can be added and updated but it lacks the functionality to
migrate code from one OSGi environment to the other. That research has delivered
a solution to the code migration problem in OSGi. It is already interesting to
know that such things are possible in OSGi and brings us allready a step further
in our solution. Unfortunately our code mobility must have some automation. We
will also use a newer version of OSGi and a lot of code in that thesis a lot of
code is deprecated.

The approach of this work has given us some insight of what is possible with
OSGi but we will start from scratch. That work lacks the automation of migrating
code and the version of OSGi is already outdated. Our research will need the
automation of migrating code. We also work with a newer version of OSGi and that
contains new and usable additions that are useful for this research.

\section{Objectives}

When we come across a Java development framework called OSGi, they are using
some marketing terms that that could reduce some problems of the above. The
framework offers an execution environment where we can add and update
executable code without restarting a system or the execution environment.

The OSGi alliance, that specified the framework, claim that their environment
has a lot of benefits in designing component based applications. We are curious
if we see these benefits when we design a multi-agent system where executable
code must be exchanged in a very dynamic way.

This does not mean that OSGi only can tackle all the problems of above. We will
need a MAS to solve the problems, but we are going to research if a MAS based on
OSGi technology will solve the stated problems.

To achieve the goal of making a code-exchanging multi-agent system based on the
OSGi architecture some preliminary steps must be done first.

Since we are going to test if the OSGi framework could be a basis for an agent
architecture we first will study the OSGi-architecture and do get some hands-on
experience with the framework. We specially will investigate how the service and
component based architecture can be used to dynamically import and export
executable code from one system to another.

Next we will make a basic design of an agent with in our minds the OSGi design
preferences. With that basic design we also have to make some decision in how
our agents will communicate and how they will order their tasks in such a way
that not tasks will be forgotten and they will be done in time.

After that the basic design of the agents together with the agreements must be
implemented in the OSGi framework. We will have to break up the agent in
different components and make a service component design of it. The agent must
be designed in such a way that tasks and/or the executable code is exchangeable
and relatively easy to implement in other applications and scanarios.

To see if our multi agent application benefits from the OSGi framework we need
to test it for our initial problems. We will set up our problem and further
implement our agents so that we put it to the test. The simulation environment
that we will use to test our application will be RinSim. This will be a demo
where we can see if our solution works.

We will not do performance tests or compare it with other applications. With
the test we just want to prove if OSGi is an architecture that could help us
developers to easily make a decent multi-agent application where it is necessary
to exchange code.

This thesis will not produce a new standardized framework for multi agent
systems based on the OSGi technology. It only consists of some draft
implementation of OSGi to represent and solve a MAS problem. It will contain
known techniques and some new insights that may invoke more research in OSGi in
a MAS context.

The specific objective for this thesis is proposing an agent architecture that
can handle a dynamic environments by offering role delegation based on code
migration.

The objective must meet these requirements :

\begin{itemize}
  \item Implement role delegation based on code migration
  \item Build up an agent architecture based on OSGi 
  \item Apply scheduling of commitments on the MAS
  \item Check if the marketing claims of OSGi also apply for an agent based
  design
\end{itemize}

To evaluate the objective we implement our architecture in a demo setting. We
will use a simuator called RinSim\cite{website:rinsim} and run a modified
General Pickup and Delivery problem to see if our objectives could be met.
Performance indicators and comparisons with other solutions are out of the scope
of this thesis.
